Date: Mon, 12 Jul 93 04:30:03 PDT
From: Packet-Radio Mailing List and Newsgroup <packet-radio@ucsd.edu>
Errors-To: Packet-Radio-Errors@UCSD.Edu
Reply-To: Packet-Radio@UCSD.Edu
Precedence: Bulk
Subject: Packet-Radio Digest V93 #205
To: packet-radio
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----------------------------------------------------------------------

Date: Mon, 12 Jul 1993 01:56:58 GMT
From: comp.vuw.ac.nz!waikato.ac.nz!aukuni.ac.nz!comu2.auckland.ac.nz!root@uunet.uu.net
Subject: bandwidth taken by packet radio?
To: packet-radio@ucsd.edu

I am looking at running a telemetry based packet system to connect the
University to my home. I have queried our Radio Frequency Service
about this, but they queried about the bandwidth taken by packet. I
was allowed something like 20Khz - would this be enough for a 1200 or
even 9600bps link?

Richard


-- 
-------------------------------------------------------------------------------
                "Is everybody happy?" - Machiavelli 

FIDONET: Richard Vowles 3:772/110.0         USENET:root@comu2.auckland.ac.nz
Packet Radio: ZL1UTF@ZL1AB.#11.AKL.NZL.OC   The Demi-Monde: 199:310/1

------------------------------

Date: 11 Jul 1993 23:27:44 GMT
From: usc!elroy.jpl.nasa.gov!kilroy!gwalsh@network.UCSD.EDU
Subject: How to supress nodes bcast in G8BPQ?
To: packet-radio@ucsd.edu

In article <742404018snx@llondel.demon.co.uk> dave@llondel.demon.co.uk writes:
>The only way you can do this is to set the route quality between the two
>nodes to a low level. If you set the QUALITY to 10 and the MINQUAL to 10
>then you should get a situation where the two nodes know about each other
>but don't pass any other route info. You cn probably set both parameters
>to a higher (but equal) level if you want both your nodes to propagate past 
>each other.
>
>Dave

Hi Dave,

That's what I thought.  One thing about the QUALITY parameter confuses
me though.  Does G8BPQ "de-rate" the quality of each individual node (as
provided by the broadcast from the node "up-stream") by a given amount?

Lets say that some node sends out a NODES bcast and that a node called
MTNTOP has a quality of 40 (as passed to my node in the bcast).  If my
QUALITY parameter for that port is set to, say 70 will the MTNTOP node (when
placed in *MY* nodes table) have a QUALITY of 70?  That would seem to 
defeat the purpose of bcasting a QUALITY.  My node should take the bcast
quality of 40 and de-reate it to something like 30 or less, shouldn't
it?

The reason I ask is that I have tried (before using news) setting the
QUALITY of the port to 50 and the MINQUAL to 20.  Only a *few* nodes
made it through that filter.

Thanks!

- Gerry

------------------------------

Date: 12 Jul 1993 02:46:20 GMT
From: swrinde!cs.utexas.edu!uwm.edu!csd4.csd.uwm.edu!anthony@network.UCSD.EDU
To: packet-radio@ucsd.edu

References <73Da7B1w165w@opus-ovh.spk.wa.us>, <21dcapINNpr1@uwm.edu>, <1993Jul7.150810.4016@news.nd.edu>
Subject : Re: Minisport Hacker - for those interested

In article <1993Jul7.150810.4016@news.nd.edu> jonathan@nova.decio.nd.edu (Jonathan Bradshaw) writes:

>Volumes 1 thru 8 are on the FTP site under 'minisport.laptop.hacker' but
>where are volumes 9 thru 15? They are NOT there.

I didn't know there were volumnes 9 through 15.  I've got 13, 14, and
15, but not 9, 10, 11, and 12.  The others will be archived as soon as
they got posted or I otherwise acquire them.
--
<-:(= Anthony Stieber	anthony@csd4.csd.uwm.edu   uwm!uwmcsd4!anthony

------------------------------

Date: Mon, 12 Jul 1993 00:39:29 GMT
From: valinor.mythical.com!n5ial!jim@uunet.uu.net
To: packet-radio@ucsd.edu

References <742011487.AA03362@psybbs.durham.nc.us>, <1993Jul9.023552.2266@n5ial.mythical.com>, <21jcer$o9d@noc.usfca.edu>4
Subject : Re: Help: KPC3 & com2

In article <21jcer$o9d@noc.usfca.edu> callis@noc.usfca.edu (Kim C. Callis)
writes:
>Jim Graham (jim@n5ial.mythical.com) wrote:
>: In article <742011487.AA03362@psybbs.durham.nc.us>
>: Kim.C..Callis%f1.n3641.z1@psybbs.durham.nc.us (Kim C. Callis) writes:
>
>: >Now being that you are using an
>: >internal modem, there should be some jumpers on it to switch the com
>: >port. What you will want to do is switch it to com 4 (because if you are
>: >using something on COM1 like a mouse, the IRQ which it shares with COM3
>: >will make the operation of one or the other [mouse and/or modem]
>: >non-existant!).
>
>: Sorry, but this is bad advicee
>
>Again, we will make the assumption that this person is using a mouse on
>COM1: and the modem is currently on COM2: .

>Since this person will not
>be using the modem simultaneously with the TNC (This is an assumption on
>my part since this person could be planning on running a voice-line BBS
>with a TNC gateway... But I doubt it.),

They might also be running packet while the modem is off doing something
else in the background (perhaps even automatic/scheduled stuff like UUCP).
Of course, whether this is the case or not isn't too important.

>it would be safe for bim to have
>this seeming IRQ conflict. Again they will not be competing for the
>interupt, since neither will be used in conjunction with the other.

Yes, but this isn't all there is to it.  Let's say the modem and the TNC
are both using IRQ3 (com2 and com4).  The modem is inactive, so IRQ3 on
the modem's serial port is basically tied low.  Meanwhile, the TNC has
incoming text, and tries to raise IRQ3.  This strip on the bus is now
attempting to be at both a +5 VDC and 0 VDC.

Does this sound like a problem?  It can be.  Sometimes, you get lucky, and
it works.  I never have...when I've tried this, one serial port works,
while the other one isn't recognized by any software I've got, including
diagnostics packages.  I have heard of cases where boards have even been
damaged by attempting to share the same interrupt.  In between these two,
you have cases where it seems to work ok, but isn't always reliable.

Now, as I mentioned before, there are board/bus combinations that are
*DESIGNED* to get around this (the inactive component would be ``floating''
instead of tied low, i.e., tri-state logic).  However, unless we know that
the person asking the question has this type of hardware, it's fairly safe
to assume that they don't (much safer than assuming that they do).

There is a reason why the documentation for so many devices tells you that
no two devices may share the same interrupt.  Besides, it's much simpler
(until you have as many external devices as people like me have!) to just
re-think your interrupt usage, and come up with a better combination that
allows more devices.  I have all of the following in use right now, and
am not using any of the higher interrupts (above IRQ7):

   serial port on com1 --- IRQ4
   serial port on com2 --- IRQ3
   bus mouse           --- IRQ5  \____  These two might be reversed....
   soundblaster        --- IRQ7  /      I'd have to check my log
   printer port        --- not using an interrupt
   IRQ2 and IRQ6 are reserved

I have a patch-panel sort of setup (using simple DB-25 cables) here that
allows me to re-configure the setup of the two serial ports, such that
any of the following devices can easily be setup to use either serial
port:

   US Robotics Dual Standard (V.32bis/HST)
   Kantronics All Mode
   MFJ 1274
   null modem (for testing between serial ports)
   serial mouse (no longer in use...)

The modem is normally on com1 (com1 is the only one with a 16550), and
the KAM is normally on com2.

All this, with only the lower interrupts...and if I wanted to, I could have
the modem running a UUCP connect, have something accessing the TNC (perhaps
running SLIP or something), have the soundblaster playing some stupid sound
file, music, etc., use the mouse for cut/paste between virtual consoles,
and have something going to the printer...all at the same time.  (In fact,
at one point, when I was compiling/testing a bunch of stuff under Linux, I
did something like this---I was compiling lots of programs at the same time
in different virtual consoles.)  Of course, having all of that going at
once assumes a multi-tasking OS (or perhaps even Desqview could handle
it?)....

   --jim

--
#include <std_disclaimer.h>                                 73 DE N5IAL (/4)
------------------------------------------------------------------------------
INTERNET: jim@n5ial.mythical.com  |  j.graham@ieee.org     ICBM: 30.23N 86.32W
AMATEUR RADIO:  (packet station temporarily offline)       AMTOR SELCAL: NIAL
------------------------------------------------------------------------------
E-mail me for information about KAMterm (host mode for Kantronics TNCs).

------------------------------

End of Packet-Radio Digest V93 #205
******************************
